Each line attached to the zs communications controller behaves as described in tty(4) and may be set to run at any of 16 speeds; see tty(4) for the encoding.
When /dev/ttya is open(2)'ed, the device driver asserts the DTR (data terminal ready) signal. Opens of the /dev/ttya device name do NOT block waiting for the RS-232 DCD (carrier detect) signal to be asserted. /dev/ttya should be specified in the file /etc/ttys for directly connected terminals.
If a serial line is opened with the /dev/ttya device name, it may not be opened with the /dev/ttyda or /dev/cua device names.
When /dev/ttyda is opened, the device driver asserts DTR and then blocks waiting for the modem to assert DCD (indicating that a connection has been established with a remote modem). When DCD is asserted by the modem the open system call returns. If DCD is deasserted by the modem, further reads and writes to the device will return the error EIO (i/o error); if the tty is the controlling terminal for the process a SIGHUP will be sent to the process.
/dev/ttyda is typically used in the file /etc/ttys for connecting modems used for dial-up logins.
If a serial line is opened with the /dev/ttyda device name, it may not be opened with the /dev/ttya. A serial line opened with the /dev/ttyda device name may also be opened with the /dev/cua device name. Interlocks between the /dev/ttyda and /dev/cua device names are described below.
When /dev/cua is opened, the device driver asserts DTR and does NOT block waiting for the modem to assert DCD. No action is taken by the driver when the modem asserts or de-asserts DCD.
/dev/cua is typically used by programs like "uucp" and "tip" that need access to auto-dial modems.
If a serial line is opened with the /dev/cua device name, it may not be opened with /dev/ttya. A serial line opened with the /dev/cua device name may also be opened with the /dev/ttyda device name. Interlocks between the /dev/ttyda and /dev/cua device names are described below.
The arbitration rules are:
NOTE: Correct functioning of these interlocks requires that the modem DCD and DTR signals be correctly configured. In particular, DCD must only be asserted when the local modem detects a remote carrier. DCD must not be continuously asserted or only be deasserted for a short period at hang-up -- many modems have this behavior by default. In addition, the modem must only auto-answer when DTR is asserted by the NeXT machine and must hang-up the connection when DTR is deasserted. Should the modem fail to follow the DCD conventions it may be impossible to use the port for dial-out use or login security may be compromised because the system is unable to detect that a remote user has disconnected and therefore not log that user out. If the modem fails to follow the DTR conventions, the system may be unable to correctly hang-up on lost connections.
To support the flow control on 68040 systems, the signals available on the serial port mini-din connector are different on 68040 systems and 68030 systems. The 68030 signals are RS-422 balanced levels. The 68040 systems provide unbalanced RS-423 (RS-232C compatible) levels.
Mini-din signals on 68030 systems
| Pin | Signal | |
| 1 | DTR | Data Terminal Ready |
| 2 | DCD | Data Carrier Detect |
| 3 | TXD- | Transmit Data Minus |
| 4 | GND | Signal Ground |
| 5 | RXD- | Receive Data Minus |
| 6 | TXD+ | Transmit Data Plus |
| 7 | A: RTXC | Receive Clock |
| B: +5v | +5 volts | |
| 8 | RXD+ | Receive Data Plus |
NOTE: Previous NeXT documentation incorrectly referred to pin 2 as CTS.
Mini-din signals on 68040 systems
| Pin | Signal | |
| 1 | DTR | Data Terminal Ready |
| 2 | DCD | Data Carrier Detect |
| 3 | TXD | Transmit Data |
| 4 | GND | Signal Ground |
| 5 | RXD | Receive Data |
| 6 | RTS | Request To Send |
| 7 | RTXC | Receive Clock |
| 8 | CTS | Clear To Send |
On 68040 systems, the /dev/ttyfa, /dev/ttydfa, and /dev/cufa (and corresponding serial port b devices) may be used to enable flow control on the serial port via the RTS and CTS signals. When the serial port is accessed via these devices, output on the port will be halted whenever the CTS signal is deasserted and resumed when CTS is asserted by the remote host. The RTS signal will be asserted by the NeXT system whenever the NeXT system can receive input on the port and will be deasserted when further input can not be accepted. When the /dev/ttyfa, etc. devices are not used (e.g. the port is opened as /dev/ttya), RTS is always asserted while the device is open and CTS is ignored.
NeXT 68030 to Modem Cable
| Mini-Din | RS-232 | |||
| 1 | (DTR) | 20 (DTR) | ||
| 2 | (DCD) | 8 (DCD) | ||
| 3 | (TXD-) | 2 (TXD) | ||
| 4 | (GND) | 7 (GND) | ||
| 5 | (RXD-) | 3 (RXD) | ||
| 8 | (RXD+) | 7 (GND) | ||
NeXT 68030 to Terminal Cable (Null-modem cable)
| Mini-Din | RS-232 | |||
| 1 | (DTR) | 8 | (DCD) | |
| 2 | (DCD) | 20 | (DTR) | |
| 3 | (TXD-) | 3 | (RXD) | |
| 4 | (GND) | 7 | (GND) | |
| 5 | (RXD-) | 2 | (TXD) | |
| 8 | (RXD+) | 7 | (GND) | |
NeXT 68040 to Modem Cable
| Mini-Din | RS-232 | |||
| 1 | (DTR) | 20 | (DTR) | |
| 2 | (DCD) | 8 | (DCD) | |
| 3 | (TXD) | 2 | (TXD) | |
| 4 | (GND) | 7 | (GND) | |
| 5 | (RXD) | 3 | (RXD) | |
| 6 | (RTS) | 4 | (RTS) | |
| 8 | (CTS) | 5 | (CTS) | |
NeXT 68040 to Terminal Cable (Null-modem cable)
| Mini-Din | RS-232 | |||
| 1 | (DTR) | 8 | (DCD) | |
| 2 | (DCD) | 20 | (DTR) | |
| 3 | (TXD) | 3 | (RXD) | |
| 4 | (GND) | 7 | (GND) | |
| 5 | (RXD) | 2 | (TXD) | |
| 6 | (RTS) | 5 | (CTS) | |
| 8 | (CTS) | 4 | (RTS) | |
NeXT 68030 to NeXT 68030 Cable (Null-modem cable)
NeXT 68040 to NeXT 68040 Cable (Null-modem cable)
NeXT 68030 to RS-422 Device (Null-modem cable)
| Mini-Din | Mini-Din | |||
| 68030 | 68030 | |||
| 1 | (DTR) | 2 | (DCD) | |
| 2 | (DCD) | 1 | (DTR) | |
| 3 | (TXD-) | 5 | (RXD-) | |
| 4 | (GND) | 4 | (GND) | |
| 5 | (RXD-) | 3 | (TXD-) | |
| 6 | (TXD+) | 8 | (RXD+) | |
| 8 | (RXD+) | 6 | (TXD+) | |
NOTE: An identically wired cable is appropriate for connecting a 68030 system to another 68030 system, or for connecting a 68040 system to another 68040 system. The signal names shown here are for 68030 systems. Also note: this cable is NOT appropriate for connecting a 68030 system to a 68040 system; use the cable described below.
NeXT 68030 to NeXT 68040 Cable (Null-modem cable)
NeXT 68040 to Some RS-422 Devices (Null-modem cable)
| Mini-Din | Mini-Din | |||
| 68030 | 68040 | |||
| 1 | (DTR) | 2 | (DCD) | |
| 2 | (DCD) | 1 | (DTR) | |
| 3 | (TXD-) | 5 | (RXD) | |
| 4 | (GND) | 4 | (GND) | |
| 5 | (RXD-) | 3 | (TXD) | |
| 8 | (RXD+) | 4 | (GND) | |
| 4 | (GND) | 8 | (CTS) | |
NOTE: This cable is symmetric and either end may be plugged into either system; the 68030 and 68040 labels simply identify the signal name conventions used for the particular column. Also note: when interconnecting 68030 and 68040 systems, the 68040 flow control device names should not be used since 68030 systems do not support flow control. This cable will allow some RS-422 devices to be used with 68040 systems; however, not all RS-422 devices will function correctly.
The delay to empty the silo may be read or altered on a per device basis by the ioctl's ZIOCTGET and ZIOCTSET. These ioctl's are used to get and set the receiver silo delay, respectively. Each ioctl takes as the third argument, the address of an int. ZIOCTGET returns the current receiver silo delay in microseconds in the int pointed to by the third argument, ZIOCTSET sets the receiver silo delay to the microsecond value pointed to by the third argument. You must include <bsd/dev/zsio.h> to get the definition of these ioctls.
zs%d: recv buffer overrun. The software input silo overflowed before it could be serviced.
zs%d: recv uart overrun. The 8530 receiver silo overflowed before it could be serviced.